幾天前筆者就開始焦慮，因為從Day 17開始，到今天測試的部分講了九天，每天老覺得哪裡還沒有說完，結果到了今天終於要把測試做一個段落了。主要的原因還是因為，這個產品老實說，相較開發人員對於程式碼的交付，與Board的部分可以密切結合的狀況大相逕庭。這件事情我與業界令人尊敬的老師，以及原廠架構師都聊過，這個產品可能真的因為價格不斐，用的人不算多，所以在社群反應的聲音並沒有真的被Azure DevOps 團隊給真的重視，那我們也只能夠在現有的產品功能下，走出一條自己使用的道路。
到底這功能要怎樣用才最適合我們使用，可能這個答案對於不同的一百個團隊，會有一百種不同的答案。原本我們在七月份有做了一個共識，我們認為嵌入式測試最適合我們用，我們只需要在Board 中看到User story上的那個Test Case被打上了小勾勾，我們應該就同意這次開發已經達到了驗收標準，因此可以進行驗收了。
這樣想其實問題也不太大，因為如果在User story (使用者需求）的驗收條件完成後，這個項目就可以交付其實非常的直觀。回到我在Day 17當天說的，我們在提出我們有測試的紀錄，其實需要兩份文件，1.開發人員測試文件 以及2.使用者測試文件 。
本來想要最簡單的滿足這兩份文件，就想說那在一個user story 中，同樣的Test Case就開兩份，一個指派給開發人員去打勾勾，一個就指派給使用者去打勾勾。 就類似下圖：
你看，多直觀，這樣不就知道開發人員或是使用者是否測試過了？
好吧，很怪。
邊寫稿邊實驗了很多天，同時也承受著先導團隊的敲碗，基於要先弄出一個解決方案出來，因此硬著頭皮把下面的使用方式給產出來了。
還是要善用Test Plan 這個功能，但不用每個人都要開啟這個昂貴的產品來進行，在我們團隊中，只有開發人員要把手上的功能進行交付測試時的時間，會開來用。
在要開始提供給人員進行測試時，建立一個這次要交付專屬的Test Plan，先不要管sprint 的問題，因為我們團隊並沒有sprint的觀念存在，但可能要有板號在 TestPlan 的最前面，因為這樣在未來release note 可以直觀的知道是哪一份Test Plan，同時在Progress report 也可以明確知道。
所有的功能需求 -User Story (Required Based Test Suite)都會需要被建立相關的Test Case。
Static Test Suite 或Query Test Suite視情況決定是否要把新增其他的測試項目，或過去的測試項目拿來做迴歸測試。
指派測試點給相關的開發人員以及使用者，記得都先別發信。
不發信的原因是，這裡有個很討厭的地方，我必須要一個個在具備test case 的test suite上(例如下圖範例中有#803 與#804 兩個required based test suite)指定測試者，沒有辦法在最上層直接遞迴的全部指派。
所以建議在所有Test suite都指派完所有測試人員，而且都不要發信通知。之後再一次從最上層指派相關測試人員，這是為了發信通知。
上述這六個步驟，就是決定該次要交付到生產環境的要求。跟據該次交付的內容，將所有測試項目都包含在測試計畫中，並且已Progress report 做為成果的展現。這個report 會在後面我們要交付的時，做為測試的依據。
另外，由於是在試行階段，所以有許多同事都說可能user不會配合進行這個測試方式。
我給的回應都是，如果他們想要繼續使用以前那種word檔案蓋章後掃描成pdf交付的方式，其實也暫時不要強迫使用者。因為短時間內要任何人改變，要是沒有強大誘因跟好處，誰願意改變原有的作法？所以即使他們使用pdf交付，換個角度想他們也是經過了真的測試的動作，只是用不同方式交付他的成果而已。
一個流程的導入，如果可以讓大部分的使用者發自內心的接受，那一定是有解決了真實世界的痛點，讓大家有強大的誘因想要使用。這樣這個流程導入才是真的成功。
因此，我們先針對資訊單位先行使用，並列入指引讓相關利害關係人都可以接受為前提，再繼續推行。
套句別人的名言：不管你要導入什麼新東西，那其實都是一種變革管理。
iThome鐵人賽
看影片追技術